Hey there!
In this lecture, I would like to show you another neat module script that allows you to create your
own events for your objects and classes that basically acts just like an RRB script signal.
These events can be useful in many ways because they allow us to continue making our code event driven.
For example, if you had a vehicle in your game that was controlled by a script that created an object
for it, that object can store events that would fire when specific things happened with the vehicle,
such as when the throttle was pressed down or an occupant went inside the vehicle, and so on.
This module script is known as Good signal, basically, and it's a class that allows us to imitate
or mimic what an RRB script signal does.
So we can connect to a signal, we can disconnect from it and things of that nature.
We can also use this module script to create custom events for our classes and custom services.
Just like how Roblox services have their own events.
For example, the player service has events like player added and player removing that can be connected
to.
If we created our own custom service and we wanted to create events for it, then this script is perfect
for that task.
The API for this module is very simple and again contains the same functions for connecting to an event
or yielding for an event.
So if we look inside of this module real quick, as you can see we can disconnect a connection.
We have functions for connecting to a signal.
We can disconnect actually all of the connections to a signal, which is pretty neat.
We can fire a signal and pass any kind of arguments we would like.
We can wait for a signal to execute, just like we could with a normal RRB script signal, and we can
even connect a function to execute once.
So when the signal fires, it will execute the function, and then it'll disconnect the function so
it doesn't, uh, run that function anymore when the signal fires again.
So it's a one time function.
So to create a new custom signal all we need to do is refer to that module script and use the new constructor
and store the return from that constructor inside of a variable.
So I'm going to refer to replicated storage where I have my module script stored.
And then I can go ahead and get my signal.
I'll just call this good signal.
And we can require it from replicated storage and get our signal module script.
And then we can go ahead and create our custom signal.
I'll just create a variable called custom signal.
And that's going to be equal to good signal.
And we use the new constructor.
And now we have our signal right here that can be connected to it can be fired.
And we can do all sorts of different stuff with it, just like we would with a normal script signal.
So for example, with our custom signal we can connect a function to it.
And this function can get any amount of arguments when the signal is fired.
And we'll just print that out here.
We can just say this signal fired with the arguments.
And then we'll just pass whatever arguments to this print function.
We can also connect once to this signal.
So we can use the once function, pass a function again get any arguments.
And we can basically just print out the exact same thing here.
And what I'm going to do is I'm going to refer to my custom signal and I'm going to fire it.
So this is how we trigger the signal and execute these functions that are connected to it.
And I'm just going to pass some random arguments like one, two and three.
And when this signal first gets fired both of these should get printed out into the console.
So we should have two of these identical print statements.
And then I'm just going to wait for like five seconds.
And then afterwards I'm going to fire the signal again and pass the same arguments.
However, this time we should only get one statement printed in the console, because this one will
get automatically disconnected because this function is only supposed to execute once, and then afterwards,
let's say we're going to disconnect all of the functions connected to the signal.
So that means if I were to copy this again and try to fire it again, none of these functions should
execute because they were all disconnected.
And then to demonstrate the wait functionality, what we can do is we can spawn a function in a new
thread.
And what we're going to do is refer to our custom signal, and we're going to wait or yield until the
signal fires.
And then afterwards we can print something like successfully yielded.
Um until event fired.
And what we'll do down here is wait for five seconds, and then we're going to fire our custom signal,
which should allow us to get to this print statement.
So now, if we run our game.
As you can see, we get both print statements inside of our console and then we should only get one.
There we go.
We only got one that time.
And then afterwards.
As you can see, nothing else printed.
But we did get the statement successfully yielded until event fired.
So the print statements match up perfectly with what we wrote in our script.
These two printed together at the exact same time, and then five seconds later, only one printed.
Because this one was automatically disconnected, we disconnected all of the functions that were listening
to our signal, which means this did absolutely nothing which we expect.
And then we were waiting for our custom signal.
And then once it fired, then we were able to reach this print statement here, which is exactly what
happened.
As you can see, this is a very simple and yet very powerful module script that allows you to implement
your own events into your scripts without having to use something like Bindable events.
This module is much better as it's not prone to memory leaks like Bindesboll's, and this is because
bind labels can cause memory leaks if you forget to clean up connections.
So this module script is a great alternative that I would highly recommend using in your games.
I will see you in the next lecture.